Perché il sito aziendale tradotto in quattro lingue racconta il prodotto in un modo, e il catalogo PDF scaricato dagli agenti all’estero ne racconta uno leggermente diverso? Succede quando traduzione e localizzazione viaggiano su binari separati, senza un brief condiviso, un glossario comune e una regia unica che tenga insieme i canali. In questo articolo vediamo cosa distingue, nella pratica, un semplice lavoro di traduzione da un progetto di localizzazione pensato per più canali; dove si creano le incoerenze tra sito e materiali stampati e come prevenirle; quali scelte tecniche sul sito (dalla segnalazione delle lingue alla gestione delle versioni) incidono sulla coerenza complessiva del progetto.
Progetto multilingua: non è tradurre testi, è allineare canali e identità
Nel linguaggio di settore si distingue di solito tra traduzione in senso stretto, che trasferisce un testo da una lingua all’altra, e localizzazione, che va oltre e adatta valute, unità di misura, riferimenti normativi ed esempi culturali al mercato di arrivo. Un terzo livello, spesso chiamato transcreation, riscrive un messaggio pubblicitario quando la traduzione letterale rischia di perdere forza o risultare fuori luogo. Sono distinzioni di uso comune tra chi lavora nel settore, più che categorie rigide: nella pratica i confini tra l’una e l’altra sfumano, e un’azienda che esporta — o un ente culturale che promuove un museo verso un pubblico internazionale — si trova spesso a dover gestire tutti e tre i livelli nello stesso progetto, anche senza chiamarli con questi nomi.
Il problema nasce quando ogni canale viene gestito a sé. Il sito passa da un fornitore, il catalogo stampato da un altro, le schede prodotto vengono tradotte internamente da chi mastica un po’ di inglese. Il risultato è un’azienda che, agli occhi di un cliente estero, sembra raccontare storie leggermente diverse a seconda di dove la incontra: un nome di prodotto scritto in modo diverso sul sito e sul catalogo, un claim che suona più rigido in una brochure e più informale online, un’unità di misura non convertita in una scheda tecnica.
Questo tipo di incoerenza non sempre si vede subito nei numeri, ma tende ad accumularsi: un cliente che nota la discrepanza può fidarsi un po’ meno, un distributore che riceve materiali disallineati perde tempo a capire quale versione sia quella corretta, ed errori su una certificazione o su una misura possono generare un problema operativo concreto, non solo un disagio estetico.
Dove si inceppano i progetti multilingua (e come prevenirlo)
Nella pratica, molti progetti multilingua vanno in crisi sempre negli stessi punti. Conoscerli prima di partire aiuta a prevenirli, e di solito costa meno che correggerli a lavoro avviato.
- Brief incompleto. Senza obiettivo chiaro, pubblico di riferimento, mercato specifico e vincoli normativi di settore, chi traduce lavora alla cieca e compensa con scelte arbitrarie.
- Nessun glossario condiviso. Nomi di prodotto, claim ricorrenti, feature tecniche, unità di misura e certificazioni dovrebbero essere resi sempre allo stesso modo, in ogni documento e in ogni lingua.
- Tono di voce non definito. Formalità, registro, eventuali varianti locali della stessa lingua: se non viene scritto da qualche parte, ogni traduttore tende a interpretarlo a modo suo.
- File e formati poco gestibili. PDF non editabili, testo incorporato nelle immagini, versioni senza tracciamento delle modifiche: tutto questo rallenta il lavoro e aumenta il rischio di errore.
- Revisione improvvisata. Se non è chiaro chi approva cosa, con quali tempi e con quali criteri di controllo qualità, le ultime correzioni arrivano spesso dopo la stampa o la pubblicazione.
Dal sito al catalogo: costruire un flusso unico e riusabile
Un progetto multicanale ben impostato segue in genere cinque passaggi, pensati per essere ripetuti ogni volta che si aggiunge una lingua o si aggiorna un materiale, senza dover ripartire da zero.
Primo passo: l’audit. Si mappano i contenuti esistenti — sito, brochure, schede prodotto, presentazioni commerciali — e si stabilisce un ordine di priorità. Non tutto deve essere tradotto subito in tutte le lingue: spesso conviene partire dalle pagine o dai documenti con il maggior peso commerciale.
Secondo passo: il kit linguistico di progetto. Glossario terminologico, guida di stile, memoria di traduzione e riferimenti visivi diventano la base comune su cui lavorano tutti i traduttori coinvolti, anche quando il team cambia nel tempo. Costruire e mantenere questo kit richiede continuità più che uno sforzo isolato a inizio progetto, e spesso significa anche rafforzare le competenze linguistiche interne, non solo quelle dei fornitori esterni. Chi vuole lavorare su questo fronte, in Ticino, può trovare un riferimento locale: a Lugano, per esempio, www.reistlingue.ch pubblica percorsi di formazione linguistica rivolti sia alle aziende sia ai privati, oltre a una sezione di domande frequenti dedicata alla formazione.
Terzo passo: la gestione delle versioni. Serve stabilire con chiarezza quale documento è il master, in quale lingua, e quali sono le versioni derivate. Senza questa distinzione, è facile ritrovarsi con tre PDF “definitivi” dello stesso catalogo, ciascuno leggermente diverso dagli altri.
Quarto passo: il controllo qualità multilivello. Non basta la revisione linguistica: vanno controllati anche la coerenza terminologica, i dati numerici (date, valute, unità di misura), i link e le call to action, soprattutto quando lo stesso contenuto compare su più canali.
Quinto passo: la manutenzione. I materiali commerciali cambiano nel tempo — nuovi prodotti, nuove certificazioni, nuovi listini — e serve una governance chiara su chi richiede un aggiornamento, chi lo valida e in quali tempi viene consegnato.
Localizzazione web: dettagli tecnici che pesano su SEO e conversioni
Quando il progetto multilingua coinvolge il sito aziendale, entrano in gioco aspetti tecnici che non riguardano direttamente la traduzione, ma determinano se un motore di ricerca mostrerà la pagina giusta all’utente giusto. Fanno parte della stessa regia unica di cui si parlava sopra: una pagina web sbagliata che arriva al visitatore contraddice il catalogo o la brochure pensati per quello stesso mercato, anche se il testo tradotto è impeccabile.
Il riferimento principale è l’attributo hreflang: un tag HTML che indica ai motori di ricerca per quale lingua e area geografica è pensata una determinata pagina, così da servire agli utenti la versione corretta e sostenere la strategia di visibilità internazionale di un sito. La sua struttura prevede tre elementi: la relazione “alternate”, il codice lingua-regione (per esempio it-ch per l’italiano di Svizzera) e l’indirizzo della pagina alternativa.
I metodi documentati per dichiarare questi riferimenti sono tre: direttamente nell’head HTML di ogni pagina, negli header HTTP per i documenti che non sono pagine web, oppure nella sitemap XML. Non sono alternative equivalenti in ogni contesto, e la scelta dipende da alcune variabili concrete. L’inserimento nell’head è l’opzione più semplice da implementare, ma richiede manutenzione costante: ogni volta che si aggiunge o si rimuove una pagina vanno aggiornati tutti i riferimenti incrociati, e su siti con molte combinazioni di lingue questo può rallentare i tempi di caricamento. Gli header HTTP diventano utili in particolare per i documenti non-HTML — una scheda tecnica in PDF, per esempio — ma condividono lo stesso limite: su siti grandi, con molte lingue, possono appesantire il caricamento. La sitemap XML resta una terza strada, spesso preferibile proprio quando il numero di pagine e combinazioni linguistiche cresce e la manutenzione diretta nell’head diventa difficile da tenere aggiornata.
Quando una lingua non ha una corrispondenza precisa con nessun mercato specifico, si può usare il valore x-default, pensato per indirizzare gli utenti la cui lingua o area geografica non trova una versione dedicata tra quelle disponibili.
Un esempio aiuta a tenere insieme i passaggi descritti finora. Un’azienda ticinese che vende apparecchiature industriali pubblica il sito in italiano, francese e tedesco, con una variante italiana pensata per il mercato svizzero (it-ch) e una per quello italiano (it-it). In fase di audit si stabilisce che la versione it-ch è il master per i contenuti rivolti alla clientela locale, mentre la it-it viene localizzata su valute, riferimenti normativi e alcuni esempi commerciali, non semplicemente tradotta. Il glossario di progetto, costruito una sola volta, accompagna sia le pagine web sia la scheda tecnica in PDF dello stesso prodotto, scaricabile in entrambe le lingue. Sul sito, i riferimenti incrociati tra le pagine lingua-mercato vengono dichiarati nell’head HTML, con il valore x-default assegnato alla versione in inglese per gli utenti che arrivano da aree non coperte dalle altre lingue; sulla scheda PDF lo stesso riferimento viene impostato nell’header HTTP del file, perché non si tratta di una pagina web. Il lavoro terminologico, fatto una volta, regge così sia il canale digitale sia quello stampabile.
Vale la pena distinguere anche un sito multilingua da uno multiregionale: il primo risponde a lingue diverse, il secondo a mercati diversi anche quando condividono la stessa lingua, come può accadere tra Italia e Svizzera italiana. Chiarire questa distinzione prima di decidere la struttura degli URL aiuta a evitare ambiguità quando si definiscono le versioni del sito.
Su un punto specifico vale la pena essere prudenti. In un thread della community di Google Search Console, un Product Expert ha segnalato che, quando due pagine pensate per mercati diversi — per esempio una versione per il Regno Unito e una per gli Stati Uniti — restano molto simili nei contenuti, il motore di ricerca può trattarle come duplicate e indicizzarne solo una, pur continuando a usare hreflang per indirizzare l’utente verso la sezione più pertinente in fase di visualizzazione. Non è una policy ufficiale documentata, ma un’osservazione emersa in un confronto tra professionisti su quel forum. In un altro thread della stessa community, risalente a qualche anno prima, un diverso Product Expert ha indicato che avere lo stesso articolo per ciascuna lingua non crea problemi, a condizione che ogni versione abbia il proprio canonical e che l’hreflang sia impostato correttamente. Le due indicazioni, lette insieme, portano a una raccomandazione prudente più che a una regola: curare canonical e hreflang con attenzione, e laddove possibile localizzare davvero i contenuti pensati per mercati distinti, non limitarsi a duplicare il testo cambiando il solo codice lingua.
Infine, un dettaglio spesso trascurato: dichiarare la lingua di una pagina tramite l’attributo lang in HTML resta utile per diverse applicazioni, dalla ricerca sensibile alla lingua fino all’applicazione di proprietà di visualizzazione specifiche per quella lingua. È una riga di codice minima, che secondo le indicazioni W3C del 2007 andrebbe comunque inserita oggi, anche in vista di sviluppi futuri legati alla gestione dei contenuti multilingua.
Cataloghi, brochure e materiali commerciali: il nodo DTP
Tradurre un catalogo non significa sostituire il testo dentro un PDF lasciando invariato il resto. Chi lavora abitualmente su questi progetti osserva spesso che alcune lingue tendono a occupare più spazio dell’originale, e che regole di sillabazione e di a capo diverse possono modificare l’ingombro di titoli, tabelle e didascalie in modo non sempre prevedibile. Se il layout non viene rivisto caso per caso, il rischio è quello di titoli tagliati o tabelle che non tornano più come nella versione di partenza.
Per questo i progetti di impaginazione su file InDesign, Illustrator o PowerPoint richiedono tempi realistici, oltre alla competenza linguistica: chi impagina dovrebbe lavorare sugli stessi file sorgente usati dal team grafico, non su un testo incollato in un documento separato. Prima della stampa, un controllo visivo incrociato tra tutte le versioni linguistiche aiuta a evitare che titoli, tabelle e didascalie risultino disallineati da una lingua all’altra.
Un’attenzione particolare va riservata a schede prodotto e listini: numeri, codici articolo, unità di misura e note legali meritano la stessa cura riservata al testo discorsivo, perché un errore in questi punti ha spesso conseguenze commerciali dirette, non solo stilistiche.
Quando serve la transcreation: claim, campagne e storytelling di marca
Ci sono contenuti che tendono a funzionare meglio se riscritti piuttosto che tradotti. Un payoff, una headline pubblicitaria, il nome di una nuova linea di prodotto: se tradotti alla lettera rischiano di perdere l’effetto che avevano in lingua originale, o nel peggiore dei casi di risultare involontariamente comici o inadeguati nel mercato di destinazione.
Un processo di transcreation tende a funzionare meglio quando prevede più alternative proposte, ciascuna accompagnata da una spiegazione del perché quella soluzione può funzionare nel mercato locale, seguita da un confronto interno e da un’approvazione esplicita prima della pubblicazione. L’obiettivo non è adattare il messaggio a tutti i costi, ma cercare un equilibrio tra identità di marca da preservare e sensibilità culturale da rispettare: un payoff può cambiare forma, ma il posizionamento che comunica dovrebbe restare riconoscibile.
Checklist pratica per scegliere un partner di traduzione per progetti multicanale
Quando un’azienda deve coordinare sito, cataloghi e materiali di vendita in più lingue, alcuni criteri aiutano a distinguere un fornitore occasionale da un partner capace di seguire il progetto nel tempo, mantenendo lo stesso glossario e la stessa logica di versioning per ogni nuovo materiale.
- Un referente di progetto unico, con un processo documentato e non improvvisato a ogni richiesta.
- Traduttori madrelingua con esperienza nel settore specifico, affiancati da una revisione indipendente.
- Uso di memorie di traduzione e glossari condivisi, che possono ridurre tempi e costi sugli aggiornamenti futuri.
- Capacità di lavorare su formati web e file di impaginazione, non solo su documenti di testo.
- Preventivi suddivisi per fase — traduzione, revisione, impaginazione, controllo qualità — con tempi indicati chiaramente.
- Policy definite su riservatezza e gestione degli accessi ai materiali, in particolare per cataloghi non ancora pubblicati o listini riservati.
Un approccio integrato: cosa cambia davvero nel lavoro quotidiano
Riutilizzare glossari e memorie di traduzione invece di ripartire da zero a ogni materiale nuovo tende, nella pratica di molti team, a semplificare gli aggiornamenti successivi, soprattutto in occasione di lanci prodotto, fiere di settore o variazioni di stagionalità, quando la finestra di comunicazione è stretta e non c’è margine per rincorrere versioni disallineate tra sito e stampa. Curare con attenzione certificazioni, condizioni contrattuali e garanzie nei materiali tradotti resta inoltre un’attenzione che, in alcuni settori, va oltre la semplice correttezza stilistica. Per chi promuove verso l’estero un prodotto, un territorio o un’offerta culturale, è questa coerenza tra i canali — dal codice lingua della pagina web alla didascalia dell’ultima pagina del catalogo — a costruire, materiale dopo materiale, la credibilità del marchio agli occhi di chi lo incontra per la prima volta in una lingua diversa dalla propria.
